Programmable Logic Devices (“PLDs”) are configurable integrated circuits (“ICs”) which can be used to implement multiple circuit designs created by users (“user designs”) without having to fabricate a new IC for each design. However, due to the complexity of the systems being implemented, such user designs usually include various design bugs, design defects, or unexpected runtime behavior that pass unseen through design and testing. Therefore, it is common for user designs to include debug functionality to aid designers and other users in identifying and correcting such bugs, defects, and behavior. Debug functionality typically includes software and hardware components that collectively or separately are referred to as the debug network of the user design, with the purpose of collecting run-time data to evaluate, detect and correct possible bugs, defects or runtime behavior.
In some cases, the debug network is implemented by using the configurable circuits of the PLD. The primary circuit structure uses the same circuits to implement the logic functionality specified within a user design. In such cases, the more complicated the debug network, the larger the amount of PLD resources consumed, leaving fewer resources for implementing the user design. As a result, user designs become less sophisticated. Additionally, a change to the functionality of the debug network will cause the entire IC design to have to be recompiled, downloaded, and loaded onto the IC. This is due to the fact that changes to a design, even when made on a small scale to localized circuits, will have a design-wide impact affecting the overall circuit routing or timing of the design. These changes also create the risk that the circuit logic, including seemingly unrelated logic, may be “broken” due to errors in implementing the new functional change. Because of this risk, extensive regression testing and verification of the logic of the primary circuit structure and debug network is required.
In other cases, the debug network is fixed-function circuitry that exists exclusively for debugging purposes. However, implementing the debugging circuitry as fixed-function circuitry also has several drawbacks. For instance, resources are dedicated to performing debug functionality whether or not the user has a need for such debug functionality. A user design that has undergone extensive regression testing and verification before implementation may require only a minimal set of debug functionality. Similarly, a user design that is only an incremental upgrade to an already existing and verified design would have little use for the debug network. Therefore, the dedicated resources of the debug network go unused and are effectively wasted as these resources cannot be modified to complement the functionality of the primary circuit structure that implements the user design.
The fixed-function implementation of the debug network required system designers to predict what functionality had to be included within the debug network. System designers had to anticipate what statistical monitoring or debug functionality was needed in advance of designing the debug network and deploying the PLD. Unanticipated usage, behavior, or operating conditions in the field could pose issues beyond the debugging scope of the programmed debug network, forcing users to have to employ third party tools or other means to perform the additional debug functionality needed to handle the unanticipated usage, behavior, or operating conditions.
A further issue prevalent in traditional debug networks is the inability of the networks to provide meaningful debug data to the users. Debug networks often blindly report data at a debug point within the user design. In many instances, the reported data has to be manually parsed or stepped through to find relevant data points at which an error occurs. As a result, users waste time in deciphering the debug data.